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(57) Abstract: Methods and apparatus for negotiating bearer control parameters using property sets. A property set is a specific set 
of default parameters or "properties" to be used for a given bearer channel type in an integrated node. Property set information can 
be passed between integrated nodes (301, 302) in a multimedia packet network (305). In many cases, a parameter negotiation can 
be completed quickly after the originating node sends a setup message including a list of one or more property sets and one or more 
requested parameters. In all cases, the bearer type and bearer parameters are determined based on capabilities of the originating 
and terminating nodes. The invention provides a way for existing signaling links using bearer independent call control (BICC), or 
session initiation protocol (SIP), or H.245, or similar protocols with a way to negotiate more bearer types and parameters without 
significantly increasing the bandwidth needed for the negotiation, or requiring nodes to be provisioned. 
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METHOD AND APPARATUS FOR NEGOTIATING BEARER CONTROL PA- 
RAMETERS USING PROPERTY SETS 

CROSS REFERENCE TO RELATED APPLICATIONS 

5 This application claims priority from co-pending, commonly assigned provi- 

sional patent applications, serial number 60/201,870, entitled, "Call Bearer Control 
information and Coding Schemes," filed May 4, 2000, and serial number 
60/217,320, entitled, "Call Bearer Control Parameters Negotiation Procedure," filed 
July 7, 2000, both of which are incorporated herein by reference. 

10 

BACKGROUND 

Field of the Invention 
This invention is related to multimedia packet networks. Specifically, this in- 
vention relates to a mechanism to allow nodes at the ends of a bearer path within a 
15 multimedia packet network to negotiate bearer parameters based on the capabili- 
ties of each node, thus facilitating open switching interfaces and reducing the need 
for provisioning. 

Description of the Problem 

20 Evolution of the PSTN has accelerated in recent years; however, most of the 

PSJN still operates on circuit switched, time division multiplexed (TDM) connec- 
tions. Integrated services digital network (ISDN) bearer channels often provide 
transport. In parallel with the PSTN, a packet based data network has evolved. 
This data network has largely been used for Internet traffic and data networking. 

25 Although these networks have been mostly separate until recently, the two net- 
works are startihg to merge. The merger of these networks requires that voice traf- 
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fic be carried over packet networks, and further that such packet networks be able 
to seamlessly integrate with traditional circuit switched networks, as the two types 
of networks may carry different call legs of the same call. 

FIG. 1 illustrates a typical TDM, PSTN call. Caller 101 places a call to callee 

5 105. The call goes through end office A, 102, over some type of trunk bearer 
channel to toll office 103, then to end office B, 105, and finally to the callee. Such 
calls may pass through multiple toll offices, or may be connected directly from one 
end office to another. In any case, a path of circuits for the call is maintained 
throughout the call. Signaling between offices is typically provided by an ISUP 

10 (ISDN user part) connection. ISUP and ISDN signaling are well understood and 
are standard in the telecommunications industry. For more information on ISUP 
signaling, see the various international Telecommunications Union (ITU) Recom- 
mendations pertaining to telephone signaling, including Q.761, Q.762, Q.763, 
Q.764 and Q.931 , the most recent versions of which at the time of filing this appli- 

15 cation are incorporated herein by reference. 

FIG. 2 illustrates a call that is similar to the TDM call of FIG. 1; however, in 
this case, the call is transported from one end office to another (called switch of- 
fices, 202 and 204, in this case) via a packet switched network 203. This fact is, in 
theory, transparent to caller 201 and callee 205. ISUP+, which is an extension of 

20 ISUP with extra fields for packet or cell based network information, can be used to 
provide signaling in this case. An International Telecommunications Union (ITU) 
recommendation was proposed for ISUP+ as ITU Q.1901 (BICC), which was re- 
cently published and is incorporated herein by reference. "BICC" stands for "bearer 
independent call control." ISUP+ and BICC are inter-changeable. Further details 
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and capabilities of ISUP+ can be found in draft ITU-T Recommendation Q. 1902, 
which is incorporated herein by reference. 

Session Initiation Protocol (SIP) is another protocol that is also used to en- 
capsulate ISUP and/or TCAP messages in packets to be used between two MGC 
5 based on packet networks. SIP is described in document RFC 2543, published by 
the Internet Engineering Task Force (IETF), March, 1999 which is incorporated 
herein by reference. IETF draft document draft-vemuri-sip-t-context-OO.txt, known 
as SIP-T, uses SIP to facilitate the interconnection of the PSTN with packet net- 
works, such as IP and ATM. 
10 Although both BICC and SIP-T can be run over either the IP or ATM net- 

works, practically, BICC is commonly used in the ATM networks and SIP-T is used 
in the IP networks. 

In order for the call leg which is handled by the packet network to seamlessly 
connect with the call legs handled by TDM switching offices, media provided by one 

15 type of network must be converted into media provided by the other. This conver- 
sion is referred to as circuit emulation services (CES) in an ATM network. The ap- 
plication is referred to as voice over ATM (VtoA). In the case of an IP network, the 
application is referred to as voice over IP (VoIP). 

The device that provides this media conversion is called a media gateway 

20 (MG). In the network of FIG. 2, a MG handles each end of the bearer connection 
through packet network 203. Each MG is associated with a media gateway control- 
ler (MGC). The MG can be stimulus in that it does not have call processing capa- 
bilities and is stateless. In that case, the call processing capabilities for the network 
reside in the MGC. An MGC provides the signaling for call control and controls the 
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call state of a MG. The MG and MGC relationship is referred to as client-server 
model. Both MG and MGC are referred to as a 'node'. 

There are many media gateway control protocols that can be used by the 
MGC to control the MG. H.248 Megaco and MGCP are two commonly used media 
5 gateway control protocols. Megaco is an application layer protocol which is also de- 
scribed in ITU-T Recommendation H.248, which shares a common text with the 
IETF standard track RFC 3015 Megaco Protocol, and which is incorporated herein 
by reference. Throughout the rest of this disclosure, we will refer to Megaco as 
"Megaco/H.248 n . MGCP is an IETF information track RFC 2705. A MGCP variant, 

10 Network Call Signaling (NCS), is described in ITU-T Recommendation J. 160, which 
is only used in the cable access networks. 

A MG and MGC at the end of a bearer connection form what is known as an 
integrated node (IN). While the media MG and the MGC were originally envisioned 
as specific hardware devices, they in fact can be implemented by many combina- 

15 tions of hardware, including multiple devices, cards within a telecommunications 
frame or one integrated device. Therefore, the integrated node is increasingly be- 
ing treated as one system containing two logical entities. The MGC corresponds to 
a logical entity called the call services function (CSF) and the media gateway corre- 
sponds to a logical entity called bearer internetworking function (BIWF) in the ITU-T 

20 Recommendation Q.1950 BICC. 

A MG can also be intelligent. In that case, the intelligent MG has the call 
processing capability. An intelligent MG does not need a MGC; instead, the intelli- 
gent MG communicates with other intelligent MG's directly. This type of MG to MG 
relationship is referred to as peer-to-peer model. ITU-T Recommendation H.323 IP 

25 phone is based on the peer-to-peer model. H.323 is a protocol suite, containing 
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many protocols. Among them, H.245 specifies the call processing functions be- 
tween two IP phones. The H.323 IP phone needs a Gateway to inter-work with the 
PSTN networks and a Gate Keeper for call authorization. 

In a PSTN, the characteristics of end points (or terminations) are either ho- 
5 mogenous or provisioned. There is no need for session establishment or bearer 
control parameter negotiation in that type of network. However, it is undesirable to 
provision integrated nodes in a packet network, since widely varying types of 
equipment from different suppliers may be used to form nodes. Additionally, many 
more factors are involved in the network connection establishment. The additional 

10 factors bring flexibility and functionality to the network; at the same time they also 
introduce complexity. The possible number of permutations of different factors can 
make the network connection establishment difficult. For example, the bearer ser- 
vice could be any of various categories of frame relay, asynchronous transfer mode 
(ATM) application layer (AAL) (AAL1, AAL2, AAL3, AAL4, and AAL5), or Internet 

15 protocol (IP) version 4 (Ipv4) or version 6 (Ipv6), or different codecs, or based on 
other services. Within each bearer type, there are many different possible configu- 
ration parameters and values. Ideally, the choice of bearer type and configuration 
parameters for a given call should be based on either user profiles, or the MG func- 
tionality; provisioning should not be required. In addition, between two MG's, many 

20 sessions can be established simultaneously. Each session can have its unique 
configuration. In that case, the configuration parameters for each session need to 
be communicated either between two MG's, or between a MG and a MGC. 

The communications of session configuration parameters can be either in- 
formative or negotiable. In the case of informative, the recipient of the configuration 

25 information will either accept or reject the configuration parameters, but will not pro- 
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vide further negotiation function with different set of parameters value to establish 
the call. As a result, the call may be abandoned, even though both ends might have 
the capabilities to complete the call. The negotiation capability can potentially in- 
crease the chance of completing a call. 
5 IETF RFC 2327 Session Description Protocol (SDP) provides the description 

for configuration parameters. SDP is based on IETF RFC 2234 ABNF syntax. SDP 
has been used by almost all protocols for communication between two MG's, or be- 
tween two MGC's, or between a MG and a MGC. SIP, BICC, H.248, MGCP, NCS, 
H.323/H.245, Q.1950, and Q.1990 all use SDP for session parameter descriptions. 

10 Most of these protocols provide the informative function rather than a negotiation 
function. There is seldom any negotiation capability between two MG's, either di- 
rectly or indirectly (such as through the MGC's). What is needed is a way to effi- 
ciently negotiate bearer channel type and parameters between two nodes within a 
multimedia packet network that can work with protocols that do not provide for di- 

15 rect negotiation. The negotiation should be based on the capabilities of each MG 
or MGC and should use as little bandwidth as possible on connections between 
nodes. The negotiation can be defined by user profiles, or by the hardware and 
software installed at the node. 

This invention also provides session configuration negotiation in SDP. There 

20 is no limitation on how this invention can be applied with different protocols, which 
use SDP. Various protocols, such as SIP, BICC, H.248, MGCP, NCS, H.323/H.245, 
Q.1950, and Q. 1990, can use this invention. 

25 
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SUMMARY 

The present invention solves the above problems by providing a way for 
existing signaling links using SIP, BICC, H.248, MGCP, NCS, H.323/H.245, 
Q.1950, and Q.1990, or similar protocols, to negotiate session configuration 
5 parameters without significantly increasing the bandwidth needed for connections, 
or requiring nodes to be provisioned. Negotiation is based on capabilities of each 
MG or MGC. Those capabilities can be defined by user profiles, or by the hardware 
and software installed at the node. The negotiation technique according to the 
invention relies on a concept called "property sets." A property set is a specific set 

10 of default parameters, or "properties," to be used for a session connection. A list of 
property sets is a list of names of property sets for specific bearer channel types 
that are within the capabilities of a given node. Each property set consists of 
parameters that a MG is capable of functioning and that the subscriber profile has 
defined. The property set information can be passed from a MG to a MG indirectly 

15 and transparently through its associated MGC. The property set information can 
also be passed between MGC's based on knowledge of their associated MG's 
(such as using H.248), or be independent to their associated MG's (such as using 
SIP). This invention is applicable to all of above cases. 

Many scenarios can happen during call establishment with the session con- 

20 figuration parameter negotiation mechanisms in the embodiment of the invention. 
According to one embodiment of the invention, an originating node in a packet net- 
work sends a setup message to the terminating node. The setup message in- 
cludes a list of one or more property sets and one or more requested parameters or 
properties for at least one property set in the list. If one of the property sets is ac- 

25 ceptable to the terminating node, the terminating node sends a connection accep- 
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tance message specifying the selected property set. The originating node then 
sends a response to the acceptance message. If the selected property set is one 
whose parameters were received in the setup message or is otherwise known to 
the terminating node, the transaction is complete. In this case, the response is a 
5 connection acknowledgment message. 

If the terminating node cannot connect using any property set and/or their 
parameter values preferred by the originating node, the terminating node will select 
a property set and send back the proposed parameter value in a connect negotia- 
tion message. If the terminating node knows the preferred parameters, but needs 

10 to change one or more of them, it sends a connection negotiation message that 
selects the property set and proposes different parameter values. In any case, if 
the terminating node proposes new parameters for a property set, the originating 
node can send a connection negotiation message to modify one or more parameter 
values suggested by the terminating node. The negotiation procedure can be re- 

15 peated to a limited number of iterations, depending on the application protocol, 
which uses the SDP. When one of the nodes accepts the property set and parame- 
ter value, it sends a connection acceptance message back to the remote node. The 
remote node replies with an optional connection acknowledgment message. 

In any case, either node can send a connection rejection message if the 

20 proposed property sets or parameters is not fully accepted by the other node. In 
many cases, a parameter negotiation can be completed quickly after the originating 
node sends the setup message including the original list of one or more property 
sets and one or more requested parameter values. 

The actual syntax of the connection messages can differ from one protocol 

25 to another. The terms of the connection messages used here are for illustration. 
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This invention provides additional SDP description for session configuration pa- 
rameters negotiation while being independent to the application protocols, which 
uses the SDP. 

The invention is implemented by software in combination with the hardware 
of the MG and possibly the MGC. The software, which implements many aspects of 
the present invention, can be stored on a media. The media can be magnetic such 
as diskette, tape or fixed disk, or optical such as a CD-ROM or a DVD-ROM. Addi- 
tionally, the software can be supplied via a network. A MG is typically implemented 
in a switching system containing switching fabrics, a computing module, network 
interfaces, and other resources. The network interfaces are implemented by adapt- 
ers which are connected to switching fabrics to allow access to the system from the 
networks. Input/output modules or adapters allow software to be loaded and vari- 
ous maintenance functions to be performed. All of these functions can be imple- 
mented on one or more of adapter cards, or in multiple stand-alone devices 
connected together. A computing module contains a processor and memory that 
execute the software and provide the means to control the operation of the MG and 
the node to implement the invention. An integrated node which implements the in- 
vention also, in one embodiment, includes a MGC function, which may be imple- 
mented by one or more adapter cards within a frame or by a type of workstation 
containing a bus such a personal computer interconnect (PCI) bus. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 conceptually illustrates a prior-art telephone connection through the 
public switched telephone network. 
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FIG. 2 conceptually illustrates a telephone connection similar to that of FIG. 
1, except that one call leg goes through a packet switched network. 

FIG. 3 is a block diagram of one network in which the present invention is 
used. FIG. 4 is a signal flow diagram illustrating the method of the present inven- 
5 tion. 

FIG. 5 is another signal flow diagram illustrating the method of the present 
invention. 

FIG. 6 is another signal flow diagram illustrating the method of the present 
invention. 

10 FIG. 7 is another signal flow diagram illustrating the method of the present 

invention. 

FIG. 8 is another signal flow diagram illustrating the method of the present 
invention. 

FIG. 9 is an example of a generic media property set that can be used with 
15 the invention. 

FIG. 10 is an example of an IP bearer property set that can be used with the 
invention. 

FIG. 1 1 is an example of a frame relay property set that can be used with the 
invention. 

20 FIG. 12 is a block diagram of a media gateway that implements a bearer in- 

ternetworking function entity the present invention. 

FIG. 13 is drawing of one media gateway controller that can be used to im- 
plement a call services function entity of the present invention. 

FIG. 14 shows an example of a media which stores software that imple- 
25 ments the present invention. 
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DETAILED DESCRIPTION OF ONE OR MORE EMBODIMENTS 

FIG. 3 illustrates one architecture in which the present invention can be 
used. According to FIG. 3, integrated node (IN) 301 is where a call originates. IN 
5 302 is where a call terminates. Bearer internetworking function (BIWF) or Media 
Gateway (MG) entity 303, is the originating or ingress BIWF/MG, Implemented on a 
media gateway platform. The terms BIWG and MG are interchangeable in this ap- 
plication. MG 304 is the terminating or egress MG. The MG entities of FIG. 3 con- 
vert various media such as TDM voice or video to packets which are passed on 

10 bearer channels through packet network 305. Packet networks usually use asyn- 
chronous transfer mode (ATM) or Internet Protocol (IP) for transport. We therefore 
refer to this network architecture as voice and telephony over ATM, or "VTOA" ar- 
chitecture or voice over IP (VoIP). However, the same architecture can be used 
with many other types of media. 

15 Call services function (CSF) or Media Gateway Controller (MGC) entity 306 

provides call server functions for MG 303, and is implemented on a media gateway 
controller (MGC) platform. The terms CSF and MGC are interchangeable in this 
application. MGC 307 provides call server functions for MG 304. By way of exam- 
ple, the MGC entities may communicate with each other via the call signaling pro- 

20 tocol BICC, but are not limited to such protocol and may also communicate using 
SIP, or H.245. It is also possible to use a nonstandard protocol, specific to the 
manufacturer of the MGC and MG's, or a different standard protocol. 

The communication protocol between a MGC and a MG can be of any media 
control protocol, such as Megaco/H.248, MGCP, NCS, etc. The connection model 

25 for the protocol describes logical entities, or objects, within the MG that can be con- 
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trolled by the MGC. The model relies on extractions, mainly terminations and con- 
texts. A termination sources and/or sinks one or more media streams. A context is 
an association between a collection of terminations within a MG. 

In general, an "add" command is used to add terminations to contexts. A 
5 termination may be moved from one context to another with a "move" command. A 
termination exists in, at most, one context at a time. A non-packet termination can 
exist outside of a context. Property values can be set for terminations by including 
appropriate descriptors as parameters to the various commands in the media con- 
trol protocol, such as Megaco/H.248, MGCP, and NCS. A termination in a context 

10 may have its value changed by the "modify" command. Other commands that are 
important to the implementation of the invention will be discussed later. 

Within the Megaco protocol, session description protocol (SDP) can be used 
to describe bearer channel termination property values in messages passed be- 
tween the CSF's and the BIWFs. SDP is described in the well-known Request for 

15 Comment (RFC) 2327, published by the Internet Engineering Task Force (IETF), 
April, 1998. In addition to RFC 2327, there have been also many IETF drafts with 
extension to RFC 2327. However, RFC 2327 and the IETF drafts with extension to 
RFC 2327 did not provide a negotiation procedure for bearer call control parame- 
ters. SDP uses an augmented Backus-Naur form (ABNF) description that can de- 

20 scribe any call bearer type and parameters, once they have been defined. SDP 
descriptors are formatted as types and values, and their characters are case sig- 
nificant. SDP is a text coding scheme. In contrast to SDP, a binary coding scheme 
can be used by a communication protocol. The pros and cons of text coding vs. bi- 
nary coding have been under debate and they are not within the scope of this in- 
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vention. The negotiation methods and syntax described in this invention are based 
on SDP; however, they can be extended to binary and other text coding as well. 

BICC currently defines addresses for BIWF's and information on CODEC'S. 
According to the invention, a new information element is added to setup messages 
5 for property sets. In the case of forwards setup, from the ingress to the egress 
node, it is necessary to signal backwards which alternative had been chosen. 
Therefore, a selected bearer alternative container element is added to connection 
acceptance messages for this purpose. The egress node can reject a parameter list 
and end the call setup. As previously mentioned, both MGC's can be either actively 

10 involved in selection of the parameter list or just let the MG's determine the list. 
The information element in the setup message is repeated to specify more choices 
of bearer types, or property sets, in priority order, thus effectively creating a list of 
property sets within the setup message. 

In FIG. 3, if the call bearer control parameters are negotiated between the 

15 peer MGC's, the ingress MGC 306 sends the property sets and some of the pa- 
rameter list to the egress MGC 307. The egress MGC can then send a revised 
property set and parameter list to the ingress MGC using the Connection Negotia- 
tion message, or send a Connection Acceptance message with the selected prop- 
erty set without modification to the parameter list of that property set. The ingress 

20 MGC then sends the egress MGC a Connection Acceptance message, or a Con- 
nection Negotiation message, or a Connection Rejection message. Both MGC's 
can repeat the negotiation messages to a limited number of iterations, depending 
on the application protocol, which uses the SDP negotiation procedure. 
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If the parameter negotiation takes place between the peer MG's, a similar 
process is applicable by replacing MGC's with MG's, except the message can be 
sent back and forth through the MGC's or directly between two MG's using their 
bearer signaling path through the packet network 305. The ingress MG 303 sends 
5 either a list of selected parameters or an empty list to the egress MG 304. The 
egress MG replies with a revised parameter list that it can support. It is redundant 
to have both the MGC and MG administrate and modify the parameter list. How- 
ever, depending on applications, the parameter list can be administrated by either 
the MGC, the MG, or both. Preferably, the bearer control related parameters are 

1 0 administrated only by the MG. 

In the case that both MGC and MG are involved in parameter negotiation, 
there are many possible scenarios. In the first scenario, the MGC's are actively in- 
volved. A MGC chooses the property set and the parameter list and passes them to 
the local MG. The local MG modifies the property set and the parameter list and 

15 passes them back to the local MGC. The MGC then negotiates the property sets 
and the parameter list with each other. 

In a second scenario, the MGC's are passively involved. A local MGC sends 
an empty list of property set and parameter list to the local MG. The local MG re- 
plies with the property sets and the parameter list to the MGC. The MGC then 

20 modifies the list before sending them to the remote MGC. The remote MGC sends 
the lists to the remote MG, which replies with the lists that it can support to the re- 
mote MGC. The remote MGC modifies the lists before sending them back to the 
local MGC. 
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Figures 4 through 8 illustrate the parameter negotiation procedure of the 
invention in signal flow diagrams. The messages are shown being transferred 
simply between originating or ingress nodes and terminating or egress nodes. Note 
that the syntax of connection messages in figures 4 to 8 are for illustration. The 
5 actual syntax of the connection messages can be different from the ones listed in 
the figures 4 to 8. Whether peer MGC's are involved in parameter negotiation or not 
is transparent from the outside of a node and has no effect on the overall method of 
the invention. 

In FIG. 4, the originating node sends a list of its property sets in order of 

10 preference to the terminating node in a setup message 401. Parameters for at 
least the most preferred property set are included in the message also, although 
parameters for more property sets from the list can be included. When the termi- 
nating node receives the property sets, it selects the property set to use based on 
the order of the list. For example, suppose the well-known ATM application layer 1 

15 (AAL1) property set is the first choice of the originating node among its property 
sets, followed by the ATM application layer 5 (AAL5) property set, and then the 
frame relay property set. If the terminating node can support the AAL1 property set 
and the listed parameters, the terminating node will accept the AAL1 property set 
and send a Connection Acceptance message 402 with the name of the chosen 

20 property set. If not, it can choose the next property set in the list as a new property 
set, in this case, AAL5, and specify that property set in Connection Acceptance 
message 402. If the terminating node cannot support AAL5, it chooses frame relay 
in this example. If the parameters are known and no parameters need to be modi- 
fied, then only the name of property set needs to be included in the Connection Ac- 

25 ceptance message. When the originating node receives the Connection 
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Acceptance message and the chosen property set is its first preference, then the 
originating node responds with a Connection Ack (acknowledgement) message, 
403. 

In FIG. 5, the terminating node chooses a property set that is not the first 
5 choice of the originating node as specified in the setup message 501 and sends a 
set of its parameters in Connection Acceptance message 502, because no parame- 
ters for the new property set were received. The originating node will have to com- 
pare the parameters of the chosen property set with its own parameters. If there 
are any differences in the parameters, the originating node has to send a Connec- 

10 tion Negotiation message 503, with new parameters for the same property set to 
the terminating node. If the new parameter value is acceptable to the terminating 
node, then the terminating node sends a Connection Acceptance message 504. 
The Connection Acceptance is the indication that the property set and parameter 
list were accepted as they are without modification. The recipient node will reply 

15 with a Connection ACK message. 

If none of the property sets can be supported, or if there is a significant mis- 
match in the parameter values (such as CODEC selection), then one of the nodes 
responds with a Connection Rejection message to its peer at some point in the 
process. Figures 6, 7 and 8 illustrate such situations. In FIG. 6, the terminating 

20 node responds to setup message 601 with a Connection Rejection message 602. 
In the Connection Rejection message, the list of supported property sets is pro- 
vided so that the originating node knows what is expected. In FIG. 7, after the ter- 
minating node receives setup message 701 it responds with a Connection 
Negotiation message 702, proposing new parameters for one of the property sets 

25 in the setup message. The originating node responds with a Connection Rejection 

SUBSTITUTE SHEET (RULE 26) 



' WO 01/84790 PCTYUS01/14596 

-17- 

message 703. In FIG. 8, setup message 801 includes the originating node's pro- 
posed property sets as before. The Connection Negotiation message 802 pro- 
poses a new set of parameters. The originating node attempts to modify those with 
a Connection Negotiation message 803, and the terminating node sends a Connec- 
5 tion Rejection message 804. 

As mentioned earlier that the syntax of the commands in the examples are 
for illustration. The actual syntax can be different, depending on the application pro- 
tocols, which implement this invention. A Connection Response message can re- 
place both the Connection Acceptance and Connection Negotiation messages. In 

10 the case that a Connection Response message is used, the node can compare the 
property sets and parameter list received with the one that it sends out. If the re- 
ceiving property sets and parameter list are a subset of the ones sent out, then the 
receiving message is a Connection Acceptance message. Otherwise, it is a Con- 
nection Negotiation message. 

15 As an example, property sets to be used with the invention can be based on 

the bearer types described in the previously discussed H.248 recommendation and 
its annexes. These include a generic media property set, a mux property set, a 
bearer capability property set, an IP bearer property set, a transport property set, a 
generic ATM property set, the previously mentioned AAL property sets such as 

20 AAL1, AAL2 and AAL5, and a frame relay property set. Parameters to be negoti- 
ated in the various property sets include, but are not limited to, quality-of-service 
(QoS) polices, security parameters, forward or backward setup selection, frame 
size or jitter buffer size, CODEC type, echo cancellation status, silence suppression 
status, companding, and parameters related to an end-to-end call identifier. 
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Examples of some of the simpler property sets are shown in Figures 9, 10, 
and 11. One of ordinary skill in the art can easily derive additional property sets 
based on the known standards discussed. In each of the figures, a PropertylD is 
given as the property or parameter name, and a numerical tag is given which indi- 
5 cates the property. The type of property and the possible values are also given. 
Values which use terms beginning with "H." or "Q." are referring to well-known In- 
ternational Telecommunication Union (ITU) recommendations. References to 
"IETF RFC" documents specify well-known Internet Engineering Task Force (IETF) 
Requests for Comments (RFC). Other acronyms are well-known and are defined in 

10 the standards. The column labeled "M/R/O" indicates whether the property is man- 
datory, recommended, or optional. Finally, an SDP equivalent is given for each pa- 
rameter. FIG. 9 shows a generic media property set, FIG. 10 illustrates an IP 
bearer property set, and FIG. 1 1 shows a frame relay property set 

According to RFC2327, connection fc-) information can be either in the 

1 5 session description section once or in the media description section once for each 
media stream. In one embodiment of this invention, different configuration parame- 
ters are preferably associated with different streams, therefore, the connection 
('c- ) information is preferably in the media description section for each property 
set. 

20. According to RFC 2327, any media ( < m=') and attribute ('a=') information 

means that all the media streams will exist simultaneously with their attribute de- 
scriptions. There is no prior known mechanism to describe different property sets 
as options and in preference order. Therefore, one embodiment of this invention 
uses a new description OPTION at the end of the media ('m^) and attribute ('a=') 

25 lines in SDP to allow for options. So, in the following example, 
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M=audio 12345 RTP/AVP 0 OPTION 
C=|N IP4 123.4.5.6 OPTION 

This allows optional parameters to be passed around during the negotiation 
stage. Without OPTION in the media ('m=') and attribute ('a=') lines, these media 
5 and attributes are required to be implemented as current RFC 2327 has specified. 

The order of the media ('m=') and attribute ('a=') lines implies their prefer- 
ence by the sender. 

For an application to implement this invention, it can follow the ABNF syntax: 
Property = 1* [media description] 
10 The operator * preceding a rule element indicates repetition of [media de- 

scription]. The number T before '*' indicates that the media description should ap- 
pear at least once. If there is a number b after '*', it means the repetition is at most 
b times. When the number after '*' is missing, it means the repetition can be infini- 
tive times. The square bracket '[ ]' signs mean that each media description is op- 
1 5 tional. The [media description] is based on the definition in RFC 2327. 

FIG. 12 illustrates a conceptual, functional block diagram of a switching sys- 
tem, which can be used to implement a media gateway, which in turn implements a 
MG which is used to carry out all or part of the method of the invention. Computing 
module 1201 includes a central processing unit, memory, and supporting circuitry. 
20 This computing module, together with any computer program code stored in the 
memory, is the means for controlling the overall operation of the switching system 
to perform the method of the invention. TDM media conversion is shown as an ex- 
ample for this particular media gateway. TDM switching fabric 1202 is for switching 
TDM channels and is controlled by the computing module. In reality, this switching 
25 fabric may also support other media besides TDM as required. Input/output (I/O) 
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module 1204 is also connected to the processor of computing module 1201 and 
includes media devices to load computer program code as well as connections for 
workstations or other equipment for control and maintenance of the switching sys- 
tem. TDM network access module 1203 serves as a TDM network interface and is 
5 connected to TDM switching fabric 1202, both of which are managed by the com- 
puting module 1201. Circuit emulation system 1205 provides circuit emulation ser- 
vices, converting TDM and other media to packets such as ATM cells. Packet 
switching fabric 1206 sends and receives packets on the packet network through 
packet network interface 1207. 

10 FIG. 13 illustrates a workstation, which can be used to implement a media 

gateway controller and hence a MGC according to the present invention. I/O de- 
vices such as keyboard 1302, mouse 1303 and display 1304 are used to control 
the system. One or more of these devices may not be present in normal operation. 
System unit 1301 is connected to all devices and contains memory, media devices, 

15 and a central processing unit (CPU) all of which together form the means to imple- 
ment the present invention. Network interfaces are normally implemented via 
adapter cards plugged into a bus, however, for the sake of simplicity they are 
shown graphically as interface 1305. The switching system of FIG. 12 and the 
workstation of FIG. 13 in this example together form an integrated node which im- 

20 plements the invention and is the means for carrying out the methods described 
herein in at least one embodiment. 

According to one embodiment of the invention, appropriate computer pro- 
gram code in combination with appropriate hardware implements most of the ele- 
ments of the present invention. This computer program code is often stored on 

25 storage media. This media can be a diskette, hard disk, CD-ROM, DVD-ROM or 
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tape. The media can also be a memory storage device or collection of memory 
storage devices such as read-only memory (ROM) or random access memory 
(RAM). Additionally, the computer code can be transferred to the workstation over 
the Internet or some other type of network. FIG. 14 illustrates one example of a 
5 media. FIG. 14 shows a diskette of the type where magnetic media 1402 is en- 
closed in a protective jacket 1401. Magnetic field changes over the surface of the 
magnetic media 1402 are used to encode the computer program code. In this way 
the computer program code is stored for later retrieval. 

This invention provides a way to negotiate network bearer channel 
10 parameters using property sets. One of ordinary skill in the networking and 
computing arts will quickly recognize that the invention has other applications. In 
fact, many embodiments and implementations are possible. The following claims 
are in no way intended to limit the scope of the invention to the specific 
embodiments described. 

15 We claim: 
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CLAIMS 

1. In an originating node in a packet network, a method of negotiating 
bearer control parameters comprising the steps of: 

sending a setup message to a terminating node, the setup message 
including a list of one or more property sets and one or more requested pa- 
rameters for at least one of the one or more property sets; 

receiving an acceptance message from the terminating node specify- 
ing a selected property set; and 

sending a response to the acceptance message to the terminating 

node. 
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1 2. The method of claim 1 wherein the response is a connection acknowl- 

2 edgement message. 

1 3. The method of claim 1 wherein the response is a connection negotiation 

2 message including at least one modified parameter, and further comprising the step 

3 of receiving a connection acknowledgement message from the terminating node. 



1 4. The method of claim 1 wherein the response is a connection rejection 

2 message. 

1 5. The method of claim 1 wherein the response is a connection negotia- 

2 tion message including at least one modified parameter, and further comprising the 

3 step of receiving a connection rejection message from the terminating node. 



4 
5 

6. The method of claim 1 wherein at least one of the one or more re- 
quested parameters for at least one of the one or more property sets is optional. 

1 7. The method of claim 6 wherein there is more than one optional pa- 

2 rameter and the optional parameters are placed in order of preference. 
3 
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4 

1 8. The method of claim 1 wherein the response is a connection negotia- 

2 tion message including at least one optional parameter and further comprising the 

3 step of receiving a connection acknowledgement message from the terminating 

4 node. 
5 

6 

1 9. The method of claim 1 wherein the response is a connection negotia- 

2 tion message including at least one optional parameter and further comprising the 

3 step of receiving a connection rejection message from the terminating node. 
4 

5 



1 10. In a terminating node in a packet network, a method of negotiating 

2 bearer control parameters comprising the steps of: 

3 receiving a setup message from an originating node, the setup rnes- 

4 sage including a list of one or more property sets and one or more requested 

5 parameters for at least one of the one or more property sets; 

6 sending a negotiation message specifying a selected property set to 

7 the originating node; and 

8 receiving a response to the negotiation message from the originating 

9 node. 



1 
2 



11. The method of claim 10 wherein the response is a connection acknowl- 
edgement message. 
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1 12. The method of claim 10 wherein the response is a connection negotia- 

2 tion message including at least one modified parameter, and further comprising the 

3 step of sending a connection acknowledgement message to the originating node. 



1 13. The method of claim 10 wherein the response is a connection rejection 

2 message. 

1 14. The method of claim 10 wherein the response is a connection negotia- 

2 tion message including at least one modified parameter, and further comprising the 

3 step of sending a connection rejection message to the originating node. 



15. The method of claim 10 wherein at least one of the one or more re- 
quested parameters for at least one of the one or more property sets is optional. 

1 16. The method of claim 15 wherein there is more than one optional pa- 

2 rameter and the optional parameters are placed in order of preference. 
3 

4 

1 17. The method of claim 10 wherein the response is a connection nego- 

2 tiation message including at least one optional parameter and further comprising 
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3 the step of receiving a connection acknowledgement message from the terminating 

4 node. 
5 

6 

1 18. The method of claim 10 wherein the response is a connection nego- 

2 tiation message including at least one optional parameter and further comprising 

3 the step of receiving a connection rejection message from the terminating node. 
4 

5 

1 19. In an originating node in a packet network, a method of negotiating 

2 bearer control parameters comprising the steps of: 

3 sending a setup message to a terminating node, the setup message 

4 including a list of one or more property sets and one or more requested pa- 

5 rameters for at least one of the one or more property sets; and 

6 receiving a connection rejection message from the terminating node. 

1 20. In a terminating node in a packet network, a method of negotiating 

2 bearer control parameters comprising the steps of: 

3 receiving a setup message from an originating node, the setup mes- 

4 sage including a list of one or more property sets and one or more requested 

5 parameters for at least one of the one or more property sets; and 

6 sending a connection rejection message to the originating node. 
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1 21 . A computer program product for enabling a node in a packet network to 

2 negotiate bearer control parameters, the computer program product including a 

3 media with a computer program embodied thereon, the computer program compris- 

4 ing: 

5 computer program code for sending and receiving setup messages, 

6 each setup message including a list of one or more property sets and one or 

7 more requested parameters for at least one of the one or more property sets; 

8 computer program code for sending and receiving acceptance mes- 

9 sages specifying a selected property set; 

10 computer program code for sending and receiving connection nego- 

1 1 tiation messages including at least one modified parameter; and 

12 computer program code for sending and receiving connection rejec- 

13 tion messages. 

1 22. The computer program product of claim 1 3 wherein all the messages 

2 are formatted according to a bearer independent call control (BICC) protocol. 

1 23. Apparatus for negotiating bearer control parameters in . a packet net- 

2 work, the apparatus comprising: 

3 means for sending and receiving setup messages, each setup mes- 

4 sage including a list of one or more property sets and one or more requested 

5 parameters for at least one of the one or more property sets; 
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6 means for sending and receiving acceptance messages specifying a 

7 selected property set; 

8 means for sending and receiving connection negotiation messages 

9 including at least one modified parameter; and 

I o means for sending and receiving connection rejection messages. 



1 24. Apparatus for use at a node in a packet network, the apparatus enabled 

2 by a computer program to negotiate bearer control parameters, the computer pro- 

3 gram comprising: 

4 computer program code for sending and receiving setup messages, 

5 each setup message including a list of one or more property sets and one or 

6 more requested parameters for at least one of the one or more property sets; 



7 computer program code for sending and receiving acceptance mes- 

8 sages specifying a selected property set without modifying parameters; 

9 computer program code for sending and receiving connection 

1 0 negotiation messages including at least one modified parameter; and 

11 computer program code for sending and receiving connection rejec- 

12 tion messages. 



1 25. The apparatus of claim 16 wherein the apparatus is a call services func- 

2 tion entity. 
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1 26. The apparatus of claim 16 wherein the apparatus is a bearer 

2 internetworking function entity. 

1 27. The apparatus of claim 16 wherein all the messages are formatted 

2 according to a bearer independent call control (BICC) protocol. 

1 28. The apparatus of claim 17 wherein all the messages are formatted 

2 according to a bearer independent call control (BICC) protocol. 

1 29. The apparatus of claim 18 wherein all the messages are formatted 

2 according to a bearer independent call control (BICC) protocol. 

1 30. A network in which bearer parameters are negotiated over connections 

2 between call services function entities within nodes, the network comprising: 

3 an originating node operable to send a setup message including a list 

4 of one or more property sets and one or more requested parameters for at 

5 least one of the one or more property sets; and 

6 a terminating node connected to the originating node, the terminating 

7 node operable to sending an acceptance message specifying a selected 

8 property set to the originating node so that bearer parameters are deter- 
g mined based on capabilities of the originating and terminating nodes. 
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